home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1732 < prev    next >
Text File  |  1995-07-25  |  9KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         M. Crispin
  8. Request for Comments: 1732                      University of Washington
  9. Category: Informational                                    December 1994
  10.  
  11.  
  12.               IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Introduction
  22.  
  23.    This is a summary of hints and recommendations to enable an IMAP4
  24.    implementation to interoperate with implementations that conform to
  25.    earlier specifications.  None of these hints and recommendations are
  26.    required by the IMAP4 specification; implementors must decide for
  27.    themselves whether they want their implementation to fail if it
  28.    encounters old software.
  29.  
  30.    IMAP4 has been designed to be upwards compatible with earlier
  31.    specifications.  For the most part, IMAP4 facilities that were not in
  32.    earlier specifications should be invisible to clients unless the
  33.    client asks for the facility.
  34.  
  35.    In some cases, older servers may support some of the capabilities
  36.    listed as being "new in IMAP4" as experimental extensions to the
  37.    IMAP2 protocol described in RFC 1176.
  38.  
  39.    This information may not be complete; it reflects current knowledge
  40.    of server and client implementations as well as "folklore" acquired
  41.    in the evolution of the protocol.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Crispin                                                         [Page 1]
  59.  
  60. RFC 1732                 IMAP4 - Compatibility             December 1994
  61.  
  62.  
  63. IMAP4 client interoperability with old servers
  64.  
  65.    In general, a client should be able to discover whether an IMAP2
  66.    server supports a facility by trial-and-error; if an attempt to use a
  67.    facility generates a BAD response, the client can assume that the
  68.    server does not support the facility.
  69.  
  70.    A quick way to check whether a server implementation supports the
  71.    IMAP4 specification is to try the CAPABILITY command.  An OK response
  72.    that includes the IMAP4 capability value indicates a server that
  73.    supports IMAP4; a BAD response or one without the IMAP4 capability
  74.    value indicates an older server.
  75.  
  76.    The following is a list of facilities that are only in IMAP4, and
  77.    suggestions for how new clients might interoperate with old servers:
  78.  
  79.    CAPABILITY command
  80.             A BAD response to this command indicates that the server
  81.             implements IMAP2 (or IMAP2bis) and not IMAP4.
  82.  
  83.    AUTHENTICATE command.
  84.             Use the LOGIN command.
  85.  
  86.    LSUB and LIST commands
  87.             Try the RFC 1176 FIND command.
  88.  
  89.    * in a sequence
  90.             Use the number of messages in the mailbox from the EXISTS
  91.             unsolicited response.
  92.  
  93.    SEARCH extensions (character set, additional criteria)
  94.             Reformulate the search request using only the searching
  95.             options listed in search_old in the IMAP4 grammar.  This may
  96.             entail doing multiple searches to achieve the desired
  97.             results.
  98.  
  99.    BODYSTRUCTURE fetch data item
  100.             Try to fetch the non-extensible BODY data item.
  101.  
  102.    body section number 0
  103.             Fetch the entire message and extract the header.
  104.  
  105.    RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
  106.             Use RFC822.HEADER and remove the unwanted information.
  107.  
  108.    BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
  109.             items Use the corresponding non-PEEK versions and manually
  110.             clear the \Seen flag as necessary.
  111.  
  112.  
  113.  
  114. Crispin                                                         [Page 2]
  115.  
  116. RFC 1732                 IMAP4 - Compatibility             December 1994
  117.  
  118.  
  119.    UID fetch data item and the UID commands
  120.             No equivalent capabilitity exists in older servers.
  121.  
  122.    FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
  123.             Use the corresponding non-SILENT versions and ignore the
  124.             untagged FETCH responses which com eback.
  125.  
  126.  
  127.    The following IMAP4 facilities were introduced in the experimental
  128.    IMAP2bis revisions to RFC-1176, and may be present in a server that
  129.    does not support the CAPABILITY command:
  130.  
  131.    CREATE, DELETE, and RENAME commands
  132.             To test whether these commands are present, try a CREATE
  133.             INBOX command.  If the response is NO, these commands are
  134.             supported by the server.  If the response is BAD, they are
  135.             not.  Older servers without the CREATE capability may sup-
  136.             port implicit creation of a mailbox by a COPY command with a
  137.             non-existant name as the destination.
  138.  
  139.    APPEND command
  140.             To test whether this command is present, try to append a
  141.             zero-length stream to a mailbox name that is known not to
  142.             exist (or at least, highly unlikely to exist) on the remote
  143.             system.
  144.  
  145.    SUBSCRIBE and UNSUBSCRIBE commands
  146.             Try the form of these commands with the optional MAILBOX
  147.             keyword.
  148.  
  149.    EXAMINE command
  150.             Use the SELECT command instead.
  151.  
  152.    flags and internal date argument to APPEND command
  153.             Try the APPEND without any flag list and internal date argu-
  154.             ments.
  155.  
  156.    BODY, BODY[section], and FULL fetch data items
  157.             Use RFC822.TEXT and ALL instead.  Server does not support
  158.             MIME.
  159.  
  160.    PARTIAL command
  161.             Use the appropriate FETCH command and ignore the unwanted
  162.             data.
  163.  
  164.  
  165.    IMAP4 client implementations must accept all responses and data for-
  166.    mats documented in the IMAP4 specification, including those labeled
  167.  
  168.  
  169.  
  170. Crispin                                                         [Page 3]
  171.  
  172. RFC 1732                 IMAP4 - Compatibility             December 1994
  173.  
  174.  
  175.    as obsolete.  This includes the COPY and STORE unsolicited responses
  176.    and the old format of dates and times.  In particular, client imple-
  177.    mentations must not treat a date/time as a fixed format string; nor
  178.    may they assume that the time begins at a particular octet.
  179.  
  180.    IMAP4 client implementations must not depend upon the presence of any
  181.    server extensions that are not in the base IMAP4 specification.
  182.  
  183.    The experimental IMAP2bis version specified that the TRYCREATE spe-
  184.    cial information token is sent as a separate unsolicited OK response
  185.    instead of inside the NO response.
  186.  
  187.    The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
  188.    are removed from IMAP4.  There is no equivalent to the bboard com-
  189.    mands, which provided a separate namespace with implicit restrictions
  190.    on what may be done in that namespace.
  191.  
  192.    Older server implementations may automatically create the destination
  193.    mailbox on COPY if that mailbox does not already exist.  This was how
  194.    a new mailbox was created in older specifications.  If the server
  195.    does not support the CREATE command (see above for how to test for
  196.    this), it will probably create a mailbox on COPY.
  197.  
  198.    Older server implementations may not preserve flags or internal dates
  199.    on COPY.  Some server implementations may not permit the preservation
  200.    of certain flags on COPY or their setting with APPEND as site policy.
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Crispin                                                         [Page 4]
  227.  
  228. RFC 1732                 IMAP4 - Compatibility             December 1994
  229.  
  230.  
  231. IMAP4 server interoperability with old clients
  232.  
  233.    In general, there should be no interoperation problem between a
  234.    server conforming to the IMAP4 specification and a well-written
  235.    client that conforms to an earlier specification.  Known problems are
  236.    noted below:
  237.  
  238.       Poor wording in the description of the CHECK command in earlier
  239.       specifications implied that a CHECK command is the way to get the
  240.       current number of messages in the mailbox.  This is incorrect.  A
  241.       CHECK command does not necessarily result in an EXISTS response.
  242.       Clients must remember the most recent EXISTS value sent from the
  243.       server, and should not generate unnecessary CHECK commands.
  244.  
  245.       An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
  246.       servers does not automatically create the destination mailbox if
  247.       that mailbox does not already exist.  This may cause problems with
  248.       old clients that expect automatic mailbox creation in COPY.
  249.  
  250.       The PREAUTH unsolicited response is new in IMAP4.  It is highly
  251.       unlikely that an old client would ever see this response.
  252.  
  253.       The format of dates and times has changed due to the impending end
  254.       of the century.  Clients that fail to accept a four-digit year or
  255.       a signed four-digit timezone value will not work properly with
  256.       IMAP4.
  257.  
  258.       An incompatibility exists with the use of "\" in quoted strings.
  259.       This is best avoided by using literals instead of quoted strings
  260.       if "\" or <"> is embedded in the string.
  261.  
  262. Security Considerations
  263.  
  264.    Security issues are not discussed in this memo.
  265.  
  266. Author's Address:
  267.  
  268.    Mark R. Crispin
  269.    Networks and Distributed Computing, JE-30
  270.    University of Washington
  271.    Seattle, WA  98195
  272.  
  273.    Phone: (206) 543-5762
  274.  
  275.    EMail: MRC@CAC.Washington.EDU
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Crispin                                                         [Page 5]
  283.  
  284.